The Internet enables a user of a client computer system to identify and communicate with millions of other computer systems located around the world. A client computer system can identify each of these other computer systems using a unique numeric identifier for that computer called an “IP address.” When a communication is sent from a client computer system to a destination computer system, the client computer system typically specifies the IP address of the destination computer system in order to facilitate the routing of the communication to the destination computer system. For example, when a request for a World Wide Web page (“Web page”) is sent from a client computer system to a Web server computer system (“Web server”) from which that Web page can be obtained, the client computer system typically includes the IP address of the Web server.
In order to make the identification of destination computer systems more mnemonic, a Domain Name System (DNS) has been developed that translates a unique alphanumeric name for a destination computer system into the IP address for that computer. The alphanumeric name is called a “domain name.” For example, the domain name for a hypothetical computer system operated by IBM Corporation may be “comp23.IBM.com”. Using domain names, a user attempting to communicate with this computer system could specify a destination of “comp23.IBM.com” rather than the particular IP address of the computer system (e.g., 198.81.209.25).
A user can also request a particular resource (e.g., a Web page or a file) that is available from a server computer by specifying a unique Universal Resource Indicator (“URI”), such as a Uniform Resource Locator (“URL”), for that resource. A URL includes a protocol to be used in accessing the resource (e.g., “http:” for the HyperText Transfer Protocol (“HTTP”)), the domain name or IP address of the server that provides the resource (e.g., “comp23.IBM.com”), and optionally a path to the resource (e.g., “/help/HelpPage.html”)—thus “http://comp23.IBM.com/help/HelpPage.html” is one example of a URL. In response to a user specifying such a URL, the comp23.IBM.com server would typically return a copy of the “HelpPage.html” file to the user.
The domain names in DNS are structured in a hierarchical, distributed database that facilitates grouping related domain names and computers. In particular, as mentioned above, a particular domain name such as “IBM.com” may identify a specific host computer. However, the hierarchical nature of DNS also allows a domain name such as “IBM.com” to represent a domain including multiple other domain names each identifying computers (also referred to as “hosts”), either in addition to or instead of identifying a specific computer. FIG. 1 illustrates a hypothetical portion of the DNS database 100 in which the node representing the IBM.com domain name 110 is the root node in an IBM.com domain 150 that includes 7 other nodes each representing other domain names. Each of these domain names in the IBM.com domain can be, but do not have to be, under the control of a single entity (e.g., IBM Corporation). FIG. 1 also includes a WebHostingCompany.com domain 155 that includes a single domain name.
As is illustrated, the DNS database can be represented with a hierarchical tree structure, and the full domain name for a given node in the tree can be determined by concatenating the name of each node along the path from the given node to the root node 101, with the names separated by periods. Thus, the 8 nodes in the IBM.com domain represent the domain names IBM.com 110, foo.IBM.com 112, foo.foo.IBM.com 118, bar.foo.IBM.com 120, bar.IBM.com 114, comp 23.IBM.com 116, abc.comp23.IBM.com 122, and cde.comp23.IBM.com 124. Other “.com” domain names outside the IBM.com domain are also illustrated in FIG. 1, including the second-level domain names BCD-Corp.com 132, WebHostingCompany.com 134, 1-800-555-1212.com 142 and 123456.com 144, and the lower-level domain names 123.123456.com 146 and 456.123456.com 148. In addition to the “.com” top-level domain (“TLD”), other TLDs are also illustrated including the “.cc” geographical TLD and the “.gov”, “.edu” and “.mil” organizational TLDs. Illustrated domain names under these other TLDs include Stanford.edu 136, Berkeley.edu 138, and RegistrarCompany.cc 140.
To facilitate the translating of DNS domain names to IP addresses, a network of domain name server computer systems (“domain name servers”) that maintain mappings from domain names to IP addresses is distributed throughout the Internet. For any particular domain name, at least one domain name server is designated as being authoritative for that particular domain name and can determine one or more IP addresses to which the particular domain name should be mapped. When another computer requests the one or more IP addresses for a domain name, an authoritative domain name server for that domain name can then make the appropriate IP addresses available to the requestor. A piece of software that is commonly used to implement the DNS protocols is the Berkeley Internet Name Domain (“BIND”) software, available from the Internet Systems Consortium. This software assists authoritative domain name servers to maintain the appropriate mapping information for domain names, and also assists other computers in identifying the domain name servers that are authoritative for a domain name when needed.
Each domain name will have one authoritative name server that is designated as the primary master name server (“primary name server”) for that domain name, and the primary name server will have control over the stored information (including the IP addresses) for that domain name. Rather than being associated directly with domain names, each name server is actually associated with one or more zones of domain names, with each zone including one or more related domain names. Thus, the primary name server for a zone will store various information about the domain names in that zone in a zone data file. If there are additional non-primary name servers that are authoritative for the domain name, these name servers are referred to as “slave name servers,” and they obtain their domain name information from the appropriate primary name server. Zone data files typically include information indicating the primary name server for the zone, slave name servers for the zone, domain name-to-IP address mappings for each domain name in the zone, domain name aliases that represent other domain names in the zone, and a serial number indicating a version of the zone data file. Each entry in the zone data file is referred to as a DNS resource record. A primary or slave name server for a zone can be a host computer associated with one of the domain names in the zone, or can instead be associated with a domain name located elsewhere in the DNS database hierarchy.
Thus, in order for a client computer to request a resource that is indicated by a URL containing a domain name, the client first determines the appropriate IP address for the domain name from one of the authoritative name servers for the zone that includes the domain name. After the name server provides the IP address to the client, the client can then use that information to contact the server computer with that IP address and request that the server provide the resource corresponding to the URL.
However, in order to obtain the IP information that corresponds to a domain name, the client computer needs to be able to identify an authoritative name server for the domain name. Requests to identify an authoritative name server for a domain name are resolved by DNS in a hierarchical manner. In particular, one or more root name servers maintain information about the authoritative name servers for each of the TLDs (e.g., “.com” and “.cc”). In response to requests, those TLD name servers can then provide information about the authoritative name servers for the second-level domains—for example, an authoritative name server for the “.com” TLD will know the authoritative name servers for the second-level IBM.com domain. Continuing in this hierarchical manner as necessary, the authoritative name servers for the domain name of interest can be identified.
The manner in which the TLD name servers obtain and store information about the second-level domains varies for different TLDs, and is affected by the domain name registrars for the TLDs. In particular, a company that serves as a registrar for a TLD assists customers in registering new domain names for that TLD and performs the necessary actions so that the technical DNS information for those domain names is stored in a manner accessible to the name servers for that TLD. Registering a domain name includes creating DNS resource records for the domain name that are stored in an appropriate location, such as a new zone file corresponding to the new domain name or in an existing zone file. Registrars often maintain a second-level domain name within the TLD (e.g., a hypothetical Registrar Company that acts as a registrar for the “.cc” TLD could maintain the RegistrarCompany.cc domain name 140), and provide an interactive Website at their domain name from which customers can register new domain names.
For the “.com”, “.net” and “.org” TLDs, a large number of registrars currently exist, and a single shared registry (“the Registry”) under the control of a third-party administrator stores information identifying the authoritative name servers for the second-level domain names in those TLDs. Thus, each of the registrars supplies the appropriate name server information to be stored in the Registry for the second-level domain names that they register, and the authoritative name servers for these TLDs obtain the delegation information about the second-level domains' authoritative name servers from the Registry. In this shared registry arrangement, the administrator of the Registry charges each registrar a fee when the registrar registers a new second-level domain name.
Other TLDs may have only a single registrar, and if so that registrar could maintain a registry for all the second-level domains in that TLD by merely storing the appropriate DNS information for each domain name that the registrar registers. In other situations, multiple registrars may exist for a TLD, but one of the registrars may serve as a primary registrar that maintains a registry for each of the second-level domains in that TLD—if so, the secondary or affiliate registrars for that TLD supplies the appropriate DNS information for the domain names that they register to the primary registrar. Thus, the manner in which the DNS information for a TLD is obtained and stored is affected by the registrars for that TLD.
In addition to registering new domain names, registrars are also responsible for maintaining administrative information (also referred to as “whois data” or a DNS whois record) about their domain names that identifies the current administrative contact for the domain name, and can include additional information such as the “registrant” (ie., owner) of the domain name, when the domain name was first created and when the administrative information was last modified.
Thus, the registering of new second-level domain names includes specifying a primary name server for the domain name, with the primary name server typically storing the technical DNS information for the domain name in a zone data file as described above. In addition to using zone data files, a primary name server typically also uses a configuration file that lists each zone for which the name server is responsible and the zone data file for that zone.
As an illustrative example, consider a zone that includes domain names foo.IBM.com 112, foo.foo.IBM.com 118, and bar.foo.IBM.com 120. FIG. 2A provides one example of a configuration file for the name server that is the primary name server for the foo.IBM.com zone, as is indicated in line 205 of the file. As is shown in the DNS configuration record in line 205, the zone data file for the foo.IBM.com is named “db.foo.IBM”. In the illustrative example, the name server is also shown in the second DNS configuration record at line 210 to be the primary name server for the stanford.edu zone. Thus, when this name server begins to execute, it will read each of the listed zone data files to obtain the zone information for those zones. Those skilled in the art will appreciate that different formatting may be used for a configuration file in different situations, such as for different versions of the BIND software.
FIG. 2B illustrates an example of a possible db.foo.IBM zone data file for the foo.IBM.com zone. As those skilled in the art will appreciate, the second and third DNS resource records in the zone data file indicate that a computer with the domain name nsl.WebHostingCompany.com (not illustrated in FIGS. 1A and 1B) is the primary name server for the foo.IBM.com zone, and that a computer with the bar.foo.IBM.com domain name is a slave name server. Other DNS resource records include a variety of other DNS information about the foo.IBM.com zone.
As mentioned above, an authoritative name server for a zone maintains information on the authoritative name servers for subzones of the zone. Thus, the authoritative name servers for the IBM.com zone need to maintain information to allow them to delegate requests about the foo.IBM.com subzone to the primary and slave name servers for that subzone, namely ns1.WebHostingCompany.com and bar.foo.IBM.com respectively. The zone data file for the IBM.com zone could include the additional entries illustrated in FIG. 2C to delegates requests about the foo.IBM.com zone to the ns1.WebHostingCompany.com and bar.foo.IBM.com domain names.
Additional details about DNS and the Bind software are available in “DNS and Bind, Third Edition” by Paul Albitz & Cricket Liu, 1998, O'Reilly & Associates Publishing, Sebastopol, Calif. 95472, which is hereby incorporated by reference in its entirety.
As indicated, requests to retrieve a Web resource identified with a URL often use the HTTP protocol. In particular, to request a resource, a Web browser will typically establish a connection with the server computer indicated in the URL, and will then send to the server an HTTP Request message (e.g., using the “GET” method) for the resource indicated by the URL. The server will typically reply with an HTTP Response message that contains the requested resource. After one or more such Request-Response message pairs are exchanged, the connection between the browser and the server computer is closed. In addition to other information included in HTTP messages, the messages can include various HTTP header fields that consist of a name followed by a colon and an optional field value (e.g., “HTTP13 HOST: comp23.IBM.com” when the URL “http://comp23.IBM.com/help/HelpPage.html” is requested). There are a variety of header fields defined by the HTTP protocol standard for use in providing additional information or instructions to the message recipient, and other non-standard header fields can also be used if the sender and recipient share an understanding of how to interpret those header fields.
Additional details about HTTP are available in “Hypertext Transfer Protocol—HTTP/1.1—Draft Standard RFC 2616”(June 1999) and in “Hypertext Transfer Protocol—HTTP/1.0—RFC 1945”(May 1996), both prepared by the World Wide Web Consortium's Network Working Group, and both of which are hereby incorporated by reference in their entirety.
While the DNS system and HTTP protocol provide many benefits, various problems exist. For example, if it is desirable to provide domain name-to-IP address mappings for very large numbers of domain names (e.g., millions or billions of second-level domain names), it is typically necessary to register each such domain name with a registrar for the appropriate TLD. In addition to the costs associated with such registering, the registry for the appropriate TLD maintains entries for each domain name, and thus uses significant storage space and has related maintenance and administrative costs. Moreover, this problem with providing domain name-to-IP address mappings becomes intractable if the specific domain names of interest cannot be identified in advance of requests for such domain names so that those domain names can be registered.
In addition to the problems with registering and storing very large numbers of IP address mappings for domain names, problems also exist for users of the Web and the DNS system who wish to obtain desired information or receive desired services. In particular, while it may be possible to identify a Website that corresponds to a particular company of interest (e.g., a user may be able to guess that the domain name “IBM.com” will provide information related to the IBM Corporation), it is much more difficult to identify an appropriate source for information or a service that is not directly related to a particular company. For example, to identify information about a particular telephone number (e.g., to do a reverse-lookup and identify the person associated with the telephone number), it would be necessary to identify a Website that could provide such a service. Even if the appropriate telephone company that is responsible for the phone number could be identified (which may be very difficult to do), and a Website for the company could be identified (which may not be possible based on mere guessing), that company may not provide a Website with the information of interest. Moreover, even if some third party was able to provide the information or service of interest, it may be difficult or impossible for an inexperienced Web user (or even for an experienced user) to identify the Website of that third party.